-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Permit per-plugin/per-listener reply-to-self #544
base: main
Are you sure you want to change the base?
Permit per-plugin/per-listener reply-to-self #544
Conversation
This commit implements a per-plugin reply-to-self functionality, allowing the bot to, for selected `listen_to` statements, reply to its own previous messages. For example, this would allow the bot to send a reply like "Hey @sender do the thing" to a trigger, and then handle its own "@sender" listener for that message. First, we turn the `EventHandler` `ignore_own_messages` into a global `mmpy_bot` setting, which defaults to `True` to preserve the existing behaviour; the bot user must turn this off to use this new feature. Second, we add a handler within the `MessageFunction` that duplicates the functionality in `EventHandler`; this ensures that the existing behaviour continues to be preserved, even if the global setting is `False`. Finally, we add another kwarg to the `listen_to` decorator to permit passing an `ignore_own_message=False` option, which would then allow that particular listener to ignore the previous conditions and reply to itself. Information about this functionality, including a warning about loops, has been added to the documentation on Plugins at the bottom of the page, to ensure users become aware of this new feature and what needs to be done to activate it.
Hi Joshua, thanks a lot for the contribution. Trying to understand the use-case and considering the risks, can you elaborate on how you envision that this will be used? My main concern is that with the above code, the more plugins you enable that use this feature, the more likely you are to potentially run into self triggers and loops, for which we currently do not have stop or control mechanisms. Understanding also that you would be using this functionality between different plugins, I would also like to contrast the proposed approach with simply calling the corresponding code/function directly. For instance, I currently have cases that seem identical to yours but instead of doing the extra round-trip between Mattermost and the bot, directly call the function that triggers the behavior.
This approach also has the advantage that most of the listener logic is refactored out into a callable function which
All this works especially well with non blocking code. |
Hey @unode no problem, happy to explain a bit. I'll preface by saying I fully understand if this is a bit to specific/esoteric for general availability or maintainability, but I figured after implementing it that it was simple enough to at least put out there! The idea of multiple function calls is of course preferable, but it won't work with what I'm doing. Consider the following two plugins:
I won't detail the code any more here since it's a bit complex, but it uses So, what I wanted to happen was to have a user be able to enter something like Hopefully that clarifies why the direct "just call both functions" method wouldn't work for what I'm trying to do, and what sort of usecases might be possible with this functionality. |
Code Climate has analyzed commit 6bff690 and detected 1 issue on this pull request. Here's the issue category breakdown:
View more on Code Climate. |
This PR implements a per-plugin reply-to-self functionality, allowing the bot to, for selected
listen_to
statements, reply to its own previous messages. For example, this would allow the bot to send a reply like "Hey @sender do the thing" to a trigger, and then handle its own "@sender" listener for that message.First, we turn the
EventHandler
ignore_own_messages
into a globalmmpy_bot
setting, which defaults toTrue
to preserve the existing behaviour; the bot user must turn this off to use this new feature.Second, we add a handler within the
MessageFunction
that duplicates the functionality inEventHandler
; this ensures that the existing behaviour continues to be preserved, even if the global setting isFalse
.Finally, we add another kwarg to the
listen_to
decorator to permit passing anignore_own_message=False
option, which would then allow that particular listener to ignore the previous conditions and reply to itself.Information about this functionality, including a warning about loops, has been added to the documentation on Plugins at the bottom of the page, to ensure users become aware of this new feature and what needs to be done to activate it.